docs(notes): measured .NET optimization limits and GC/LOH observability - #327

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@docs/notes/gc-observability-and-loh.md`:
- Around line 15-28: Update the LOH sizing guidance to account for effective
runtime configuration rather than treating 85,000 as universal: mention that
System.GC.LOHThreshold or DOTNET_GCLOHThreshold may override the default, and
avoid asserting a fixed 24-byte array header because object layout and alignment
vary by platform. Identify the measured environment, such as .NET 9 CoreCLR x64,
or make the recommendation simply to measure.
- Around line 56-63: Revise the GC probe description to identify
GC.CollectionCount(n) and GC.GetGCMemoryInfo() as process-wide heuristics
affected by prior, parallel, or background collections, not isolated scenario
snapshots. Before using the probe as an assertion, record the collection count
at the scenario boundary and compare GetGCMemoryInfo() only when the
corresponding GC index matches; retain the existing debug-only caveat.

In `@docs/notes/invariant-cost-data/Program.cs`:
- Around line 51-56: Update the comment above C_Inline to describe
OrderBy(...).First() as repeated linear scanning and key comparison via LINQ’s
specialized path, not allocation and full sorting on every iteration. Keep the
benchmark code unchanged unless the intended measurement is full sorting, in
which case enumerate the ordered sequence before taking the first element.
- Around line 94-99: Update Row to evaluate inline() and hoisted() before
calling Bench, and throw when their results differ instead of only appending a
mismatch marker; keep timing and output for equivalent implementations unchanged
so run.sh receives a non-zero exit status on failure.
- Around line 34-39: Rename the shape B benchmark label and its corresponding
Markdown row to explicitly describe Count() on a Select-wrapped sequence rather
than all IEnumerable<T> values. Update the visible labels around B_Inline and
the matching section near the later referenced lines, while leaving the
benchmark implementation unchanged.

In `@docs/notes/invariant-cost-data/run.sh`:
- Line 3: Update the run script’s .NET SDK requirement so it either enforces SDK
version 9.0.316 and reports the selected runtime with dotnet --info, or revise
the documentation to explicitly support any .NET 9 patch version. Ensure the
measurement command’s actual SDK/runtime selection is visible and consistent
with the reproducibility claim.
- Around line 5-7: Update the run script’s WORK initialization to track whether
the directory was created by the script, then register an EXIT trap that removes
only that owned temporary directory. Preserve caller-provided WORK directories
without deleting them.
- Around line 10-11: Update the benchmark mode labeling in
docs/notes/invariant-cost-data/run.sh lines 10-11 and
docs/notes/invariant-cost-static-vs-runtime.md lines 19-22 to consistently
describe DOTNET_TieredCompilation=0 as non-tiered mode, removing references to
tier-1 measurement unless the benchmark is intentionally changed to measure
tier-1 promotion.

In `@docs/notes/invariant-cost-static-vs-runtime.md`:
- Around line 42-45: Revise the conclusion in “The dynamic range is three orders
of magnitude” to limit claims to the measured sample: replace “costing exactly
nothing” with “no measurable penalty in this run,” and replace “useless for
prioritisation” with “cannot prioritize this sample without runtime data.”
- Around line 116-118: Update the statement in the .NET 4.7.2 measurement
discussion to remove the unsupported “lower bound” inference and describe the
.NET 9 results as not comparable to .NET Framework. Retain the fact that .NET
4.7.2 was not measured, and only make a lower-bound claim if matched Framework
measurements are added.
- Around line 54-56: Revise the claim in the discussion around Main and A_Inline
to scope it to analyzers that lack runtime or call-site input values.
Acknowledge that whole-program analysis can distinguish the benchmark’s
deterministic Enumerable.Range and constant arguments, while preserving the
conclusion that a local rule cannot predict costs for unknown general inputs.

In `@docs/notes/llvm-codegen-feasibility-data/Kernels.cs`:
- Around line 135-142: Update the K3 correctness gate around FilterSumManaged,
FilterSumBranchless, FilterSumSimd, FilterSumNative, and FilterSumFree to define
a named expected-result constant of 25830282 and validate r0 against it before
the existing pairwise implementation comparisons; retain the current mismatch
reporting for disagreements between variants.

In `@docs/notes/llvm-codegen-feasibility.md`:
- Around line 44-48: Update the K3 correctness-gate text to state that the
harness checks five variants, adding both native implementations—per-element
check and hoisted check—to the existing scalar, branchless, and hand-SIMD list.